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Foreword 

This Technical Specification has been produced by the 3GPP. 

The contents of the present document are subject to continuing work within the TSG and may change following 
formal TSG approval. Should the TSG modify the contents of this TS, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version 3.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 Indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the specification; 
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1 Scope 



Existing systems have largely standardised the complete sets of bearer services, teleservices and supplementary 
services which they provide. 3GPP specifications specify service capabilities rather than services, allowing service 
differentiation and system continuity. This Technical Specification (TS) describes how and what kind of services the 
user has access to. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the 
present document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

• A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the 
same number. 

2.1 Normative references 

[I] TS 22.001: "Principles of circuit telecommunication services supported by a Public Land 
Mobile Network (PLMN)". 

[2] TS 02.002: " Circuit Bearer services supported by a Pubhc Land Mobile Network (PLMN)". 

[3] TS 22.003: "Circuit Teleservices supported by a GSM Public Land Mobile Network (PLMN)". 

[4] TS 22.004: " General on supplementary services". [5] TS 22.038: " SIM toolkit Stage 1". 

[6] TS 22.057: " Mobile Station Application Execution Environment (MExE); Service description; 

Stage 1". 

[7] TS 22.060: "General Packet Radio Service (GPRS) stage 1". 

[8] TS 22.078: " Customised Applications for Mobile network Enhanced Logic (CAMEL); Service 

definition - Stage 1". 

[9] TS 22.101: " Service principles". 

[10] TS 22.121: " Virtual Home Environment (VHE), Stage 1". 

[II] TS 22.135: "Multicall, stage 1". 



2.2 Informative references 



[12] ITU-T recommendation F.700: "Framework recommendation for audio-visual/multimedia 

services". 
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3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of this TS, the following definitions apply: 

Basic telecommunication service : this term is used as a common reference to both bearer services and 
teleservices. 

Bearer service : is a type of telecommunication service that provides the capability of transmission of signals 
between access points. 

Call : a logical association between several users (this could be connection oriented or connection less). 

Connection : is a communication channel between two or more end-points (e.g. terminal, server etc.). 

Mobile termination : the mobile termination is the component of the user equipment which supports functions 
specific to management of the radio interface (Um). 

Multimedia service : Multimedia services are services that handle several types of media. For some services, 
synchronisation between the media is necessary (e.g. synchronised audio and video). A multimedia service may 
involve multiple parties, multiple connections, and the addition or deletion of resources and users within a single 
call. 

Nomadic Operating Mode : Mode of operation where the terminal is transportable but being operated while 
stationary and may in addition require user co-operation (e.g. close to open spaces, antenna setup...). 

Quality of Service : the collective effect of service performances which determine the degree of satisfaction of a 
user of a service. It is characterised by the combined aspects of performance factors applicable to all services, such 
as; 

service operability performance; 

service accessibility performance; 

service retention performance; 

service integrity performance; and 

other factors specific to each service. 

Service Capabilities: Bearers defined by parameters, and/or mechanisms needed to realise services. These are 
within networks and under network control. 

Service Capability Feature: Functionality offered by service capabihties that are accessible via the standardised 
application interface 

Services: Services are made up of different service capability features. 

Supplementary service : is a service which modifies or supplements a basic telecommunication service. 
Consequently, it cannot be offered to a user as a standalone service. It shall be offered together with or in association 
with a basic telecommunication service. The same supplementary service may be common to a number of basic 
telecommunication services. 

Teleservice; is a type of telecommunication service that provides the complete capability, including terminal 
equipment functions, for communication between users according to standardised protocols and transmission 
capabilities established by agreement between operators. 
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3.2 



Abbreviations 



For the purposes of this TS, the following abbreviations apply; 

BER Bit Error Rate 

CAMEL Customised Application for Mobile network Enhanced Logic 

DTMF Dual Tone Multiple Frequency 

TR Technical Report 

TS Technical Specification 

ETSI European Telecommunications Standards Institute 

FAX Facsimile 

FER Frame Erasure Rate 

GSM Global System for Mobile Communications 

GERAN GSM / EDGE Radio Access Network. 

HE Home Environment 

IN Intelligent Network 

ISDN Integrated Services Digital Network 

ITU International Telecommunication Union 

LCS Location Services 

MExE Mobile station Execution Environment 

MMI Man Machine Interface 

MO Mobile Origination 

MT Mobile Termination 

PC Personal Computer 

PIN Personal Identity Number 

PNP Private Numbering Plan 

POTS Plain Old Telephony Service 

QoS Quality of Service 

USIM User Service Identity Module 

SMS Short Message Service 

SAT SIM AppHcation Toolkit 

SN Serving Network 

SoLSA Support of Localised Service Area 

UE User Equipment 



Framework for the description of 
telecommunication services and applications 



4.1 



General 



Telecommunication services defined by 3GPP specifications are the communication capabilities made available to 
users by home environment and serving network. A PLMN provides, in co-operation with other networks, a set of 
network capabilities which are defined by standardised protocols and functions and enable telecommunication 
services to be offered to users. 

A service provision by a HE/SN to a user may cover the whole or only part of the means required to fully support 
the service. 

The service classification and description which follow are independent of different possible arrangements for the 
ownership and provision to the user of the means required to support a service. 
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4.2 



Basic telecommunication services 



Basic telecommunication services are divided in two broad categories; 

bearer services, which are telecommunication services providing the capability of transmission of signals 
between access points; 

teleservices, which are telecommunication services providing the complete capability, including terminal 
equipment functions, for communication between users according to protocols established by agreement 
between network operators. 

The communication link between the access points may consist of PLMN, one or more transit networks and a 
terminating network. The networks between the two access points typically use different means for bearer control. 

Figure 1 illustrates these definitions. 
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UE: User Equipment 
MT: Mobile Termination 
TE: Terminal Equipment 
TAP: Teminal Adaption Function 



NOTE 1 : In order to limit the complexity of the figure, only one transit network is shown. 

NOTE 2: The terminating network type may include a PLMN, either the originating one or another one. 

NOTE 3: The bearer service terminates in the user equipment. 

NOTE 4: The terminating network may be another network such as: PSTN, ISDN, IP networks/LANs and X.25 

Figure 1 ; Basic telecommunication services supported by a PLMN 



4.2.1 



Bearer services 



The characterisation of a bearer service is made by using a set of characteristics that distinguishes it from other 
bearer services. Particular values are assigned to each characteristic when a given bearer service is described and 
defined. 

The service characteristics as they apply at a given reference point where the user accesses the bearer service. 

In the general case networks between the two access points use different control mechanisms. In this case the bearer 
services of each network throughout the communication link have to be translated at the network interfaces to 
realize an end to end bearer service. 
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A list of definitions of attributes and values used for bearer services is contained in clause 5. 
The bearer services are negotiable and can be used flexibly by applications. 

4.2.2 Teleservices 

Section 6 defines both standardised and non-standardised teleservices. Some teleservices are standardised because 
that interworking with other systems have been recognised as a requirement. Other teleservices will not be 
standardised. A decoupling between lower layer (i.e. bearer attributes) and higher layer capabilities will be 
necessary for the development of teleservices. 



4.3 Supplementary services 



A supplementary service modifies or supplements a basic telecommunication service. Consequently, it cannot be 
offered to a user as a stand alone service. It shall be offered together or in association with a basic 
telecommunication service. The same supplementary service may be applicable to a number of basic 
telecommunication services. 

Two methods are used for the characterisation of supplementary services; 

The first method is used for the description of existing standardised supplementary services. These services 
are specified through the detailing of each of the operations involved in service provision and service usage 
(the provision/withdrawal, registration/erasure, activation/deactivation, invocation and interrogation 
operations). Clause 7 lists these services. 

The second method enables the provision of HE/SN specific supplementary services. To make this possible, 
services can be built using service capability features which are accessed via the standardised application 
interface. 

A PLMN shall be able to handle multiple supplementary services within a call. Interactions shall be handled when 
several supplementary services are activated in the same call.. When multiple supplementary services can be 
activated concurrently, some prioritisation of the services will be necessary. Certain services may override or 
deactivate other services. 

Interactions between operator specific supplementary services are not defined. 

The following issues need consideration when interactions between services occur; 

Different phases of a call. 

A service spanning on more than one network. 

Service interactions that may occur between services offered to a single user, as well as between services 
offered to different interacting users. 

NOTE: The methods defined for characterisation of services are description methods. They do not imply or 
restrict different implementations. 



4.4 Service Capabilities 



Service capabilities are based on functionality and mechanisms/toolkits such as provided by SAT [5], MExE [6], IN 
and CAMEL [8]. These service capabilities can be made visible to the applications through an application interface. 
See clause 8 for service capability features. 
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5 Bearer Services 

5.1 Definition of bearer services 

Bearer services provide the capability for information transfer between access points and involve only low layer 
functions. These functions are sometimes referred as low layer capabilities (in reference to OSI layers). The user 
may choose any set of high layer protocols for his communication and the PLMN does not ascertain compatibility at 
these layers between users. 

In the general case a communication link between access points provides a general service for information transport. 
The communication link may span over different networks such as Internet, Intranets, LANs and ATM based transit 
networks, having network specific means for bearer control. Each network contributes to the end-to-end QoS 
perceived by the end-user. 

PS and CS domains provide a specific set of bearer capabilities. The Circuit bearer services are described in 22.002 
[2]. The packet services (GPRS) is described in TS 22.060 [7]. Following chapters describe the overall requirements 
for both the CS and PS domain bearers and also for the bearers used by teleservices. 



5.2 Description of bearer services 



Bearer services are characterised by a set of end-to-end characteristics with requirements on QoS. The 
characteristics and requirements shall cover major network scenarios, i.e. the cases when the terminating network is 
PSTN, ISDN, GSM, IP networks/LANs, X.25 and a PLMN. 

Quality of Service is the quality of a requested service (Teleservice or Bearer Service or any other service, e.g. 
customer care) as perceived by the customer (ITU-T M.xxxx). QoS is always meant end-to-end. Network 
Performance of several network elements of the originating and terminating network(s) contribute to the QoS as 
perceived by the customer including terminals and terminal attachments. In order to offer the customer a certain 
QoS the serving network need to take into account network performance components of their network, reflect the 
performance of the terminal and ad sufficient margin for the terminating networks in case network performance 
requirements cannot be negotiated. 

As far as the QoS to the subscriber is concerned network elements have to provide sufficient performance (reflecting 
possible performance constraints in terminating networks) so that the PLMN cannot be considered as a bottleneck. 

This section outlines the requirements on bearer services in two main groups; 

Requirements on information transfer, which characterise the networks transfer capabilities for transferring 
user data between two or more access points. 

Information quality characteristics, which describe the quality of the user information transferred between 
two or more access points. 

It shall be possible to negotiate / re negotiate the characteristics of a bearer service at session / connection 
establishment and during an on going session / connection. 

5.2.1 Information transfer 

Connection oriented / connectionless services 

Both Connection oriented and connectionless services shall be supported. 

Traffic type- It is required that the bearer service provides one of the following: 
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guaranteed/constant bit rate, 
non-guaranteed/dynamically variable bit rate, and 

real time dynamically variable bit rate with a minimum guaranteed bit rate^. 
Real time and non real time applications shall be supported. 

Real time video, audio and speech shall be supported. This implies the: 

ability to provide a real time stream of guaranteed bit rate, end to end delay and delay variation. 

ability to provide a real time conversational service of guaranteed bit rate, end to end delay and delay variation. 

Non real time interactive and file transfer service shall be supported. This implies the: 

ability to support message transport with differentiation as regards QoS between different users. 

Multimedia applications shall be supported. This implies the: 

ability to support several user flows to/from one user having different traffic types (e.g. real time, non real time) 

Traffic characteristics 

It shall be possible for an application to specify its traffic requirements to the network by requesting a bearer service 
with one of the following configurations 

1) Point-to-Point 

Uni-Directional 
Bi-Directional 

Symmetric 

Asymmetric 

2) Uni-Directional Point-to-Multipoint 

- Multicast 

- Broadcast 

A multicast topology is one in which sink parties are specified before the connection is established, or by subsequent 
operations to add or remove parties from the connection. The source of the connection shall always be aware of all 
parties to which the connection travels. 

A broadcast topology is one in which the sink parties are not always known to the source. The connection to 
individual sink parties is not under the control of the source, but is by request of each sink party. 

Note: Point-to-multipoint services are not supported by release 99 specifications. 

In the case of a mobile termination with several active bearer services simultaneously, it shall be possible for each 
bearer service to have independent configurations and source/sink parties. 



5.2.2 Information Quality 
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Information quality a characterises the bit integrity and delay requirements of the applications. 
Other parameters may be needed. 

Maximum transfer delay 

Transfer delay is the time between the request to transfer the information at one access point to its delivery at the 
other access point. In clause 5.5 requirements on maximum transfer delay is defined. 

Delay variation 

The delay variation of the information received information over the bearer has to be controlled to support real-time 
services. The possible values for delay variation are not a limited set, but a continuous range of values. 

Bit error ratio 

The ratio between incorrect and total transferred information bits. The possible values for Bit error ratio are not a 
limited set, but a continuous range of values. 

Data rate 

The data rate is the amount of data transferred between the two access points in a given period of time. 



5.3 Supported bit rates 



It shall be possible for one application to specify its traffic requirements to the network by requesting a bearer 
service with any of the specified traffic type, traffic characteristics, maximum transfer delay, delay variation, bit 
error ratios & data rates. It shall be possible for the network to satisfy these requirements without wasting resources 
on the radio and network interfaces due to granularity limitations in bit rates. 

It shall be possible for one mobile termination to have several active bearer services simultaneously, each of which 
could be connection oriented or connectionless. 

The only limiting factor for satisfying application requirements shall be the cumulative bit rate per mobile 
termination at a given instant (i.e. when summing the bit rates of one mobile termination's simultaneous connection 
oriented and connectionless traffic, irrespective of the traffic being real time or non real time) in each radio 
environment: 

• At least 144 kbits/s in satellite radio environment (Note 1). 

• At least 144 kbits/s in rural outdoor radio environment. 

• At least 384 kbits/s in urban/suburban outdoor radio environments. 

• At least 2048 kbits/s in indoor/low range outdoor radio environment. 

Note 1 : This Peak Bit Rate may only be achieved in a nomadic operating mode. 
Note 2: Not supported by GERAN. 



5.4 Range of QoS requirements 



It shall be possible for one application to specify its QoS requirements to the network by requesting a bearer service 
with any of the specified traffic type, traffic characteristics maximum transfer delay, delay variation, bit error ratios 
& data rates. 
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The following table indicates the range of values that shall be supported. These requirements are valid for both 
connection and connectionless traffic. It shall be possible for the network to satisfy these requirements without 
wasting resources on the radio and network interfaces due to granularity limitations in QoS. 





Real Time (Constant Delay) 


Non Real Time (Variable Delay) 


Operating 
environment 


BER/Max Transfer Delay 


BER/Max Transfer Delay 


Satellite 
(Terminal 
relative speed to 
ground up to 
1000 km/h for 
plane) 


Max Transfer Delay less than 400 ms 

BER 10-3 -10-7 
(Notel) 


Max Transfer Delay 1200 ms or more 
(Note 2) 

BER= 10-5 to 10-8 


Rural outdoor 
(Terminal 
relative speed to 
ground up to 500 
km/h) (Note 3) 


Max Transfer Delay 20 - 300 ms 

BER 10-3 -10-7 
(Notel) 


Max Transfer Delay 1 50 ms or more 

(Note 2) 

BER= 10-5 to 10-8 


Urban/ Suburban 
outdoor 
(Terminal 
relative speed to 
ground up to 120 
km/h) 


Max Transfer Delay 20 - 300 ms 

BER 10-3 -10-7 
(Note 1 ) 


Max Transfer Delay 150 ms or more 
(Note 2) 

BER= 10-5 to 10-8 


Indoor/ Low 
range outdoor 
(Terminal 
relative speed to 
ground up to 10 
km/h) 


Max Transfer Delay 20 - 300 ms 

BER 10-3 -10-7 
(Notel) 


Max Transfer Delay 150 ms or more 
(Note 2) 

BER= 10-5 to 10-8 


NOTE 1 ; There is likely to be a compromise between BER and delay. 

NOTE 2; The IVIax Transfer Delay should be here regarded as the target value for 95% of the data. 

NOTE 3; The value of 500 km/h as the maximum speed to be supported in the rural outdoor environment 
was selected in order to provide service on high speed vehicles (e.g. trains). This is not meant 
to be the typical value for this environment (250 km/h is more typical). 
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5.5 Supported End User QoS 



This section outlines the QoS that shall be provided to the end user / applications. This section defines QoS 
requirements from end to end. The values in the tables are end to end, including mobile to mobile calls and satellite 
components. Figure 2 below summarises the major groups of application in terms of QoS requirements. 
Applications and new applications may be appUcable to one more groups. 



Error 
tolerant 


Conversational 
voice and video 


Voice messaging 


Streaming audio 
and video 


Fax 


Error 
intolerant 


Telnet, 
interactive games 


E-commerce, 
WWW browsing, 


1- 1 P, still image, 
paging 


E-mail arrival 
notification 



Conversational Interactive Streaming Background 

(delay «1 sec) (delay approxl sec) (delay <10 sec) (delay >10 sec) 



The following tables further elaborate end user / application QoS requirements. 

Table 1 : End-user Performance Expectations - Conversational / Real-time 
Services 



Medium 


Application 


Degree of 
symmetry 


Data rate 


Key performance parameters and target values 










One-way 
Delay 


Delay 
Variation 


Information 
loss 


Audio 


Conversational 
voice 


Two-way 


4-25 lib/s 


< 150 msec 
preferred 
<400 msec limit 


< 1 msec 


< 3% FER 
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Video 


Videophone 


Two-way 


32-384 
kb/s 


< 150 msec 
preferred 

<400 msec limit 

Lip-synch : < 100 
msec 




<1%FER 


Data 


Telemetry 

- two-way 
control 


Two-way 


<28.8 kb/s 


< 250 msec 


N.A 


Zero 


Data 


Interactive games 


Two-way 


<1KB 


< 250 msec 


N.A 


Zero 


Data 


Telnet 


Two-way 

(asymmetri 
c) 


<1KB 


< 250 msec 


N.A 


Zero 
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Table 2: End-user Performance 
Expectations - Interactive Services 



Medium 


Application 


Degree of 
symmetry 


Data rate 


Key performance parameters and target values 










One-way 
Delay 


Delay 
Variation 


Information loss 


Audio 


Voice messaging 


Primarily 
one-way 


4-13 kb/s 


< 1 sec for 
playback 

< 2 sec for 
record 


< 1 msec 


< 3% PER 


Data 


Web-browsing 
-HTML 


Primarily 
one-way 




< 4 sec /page 


N.A 


Zero 


Data 


Transaction 
services - high 
priority e.g. e- 
commerce, ATM 


Two-way 




< 4 sec 


N.A 


Zero 


Data 


E-mail 
(server access) 


Primarily 
One-way 




< 4 sec 


N.A 


Zero 



Table 3: End-user Performance Expectations - Streaming Services 



Medium 


Application 


Degree of 
symmetry 


Data rate 


Key performance parameters 


and target values 










One-way 
Delay 


Delay 
Variation 


Information loss 


Audio 


High quality 
streaming audio 


Primarily 
one-way 


32-128 
kb/s 


< 10 sec 


< 1 msec 


<1%FER 


Video 


One-way 


One-way 


32-384 
kb/s 


< 10 sec 




<1%FER 
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Data 


Bulk data 
transfer/retrieval 


Primarily 
one-way 




< 10 sec 


IN. A 


Zero 


Data 


Still image 


One-way 




< 10 sec 


N.A 


Zero 


Data 


Telemetry 
- monitoring 


One-way 


<28.8 kb/s 


< 10 sec 


N.A 


Zero 
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5.6 Radio Interface optimisation 

The following requirements shall lead the radio interface optimisation process; 

support of high bit rate (around the Peak Bit Rate), bursty, asymmetric, non-real time bearer capabilities; 

support of high bit rate (around the Peak Bit Rate), bursty, asymmetric, real time bearer capabilities; 

the ability to extend or reduce the bandwidth associated with a bearer capability in order to adapt to bit rate or 
radio condition variations, and to add or drop service components. 

However, the services provided by existing systems (speech in particular) shall be supported in a spectrally efficient 
manner (at least as efficiently as in GSM) for the same quality of service. 

In order to allow the support of flexible, bandwidth on demand services, bearer services should be provided with the 
finest possible granularity that can be efficiently supported. 



6 Teleservices 

6.1 Definition of teleservices 

Teleservices provide the full capabilities for communications by means of terminal equipment, network functions and 
possibly functions provided by dedicated centres. 



6.2 Description of teleservices 



The basic reference for the description of teleservices is the ITU-T F.700 [12] recommendation. F.700 provides a 
generic, network independent, description of multimedia services. The methodology used covers both single media and 
multimedia services, the single media services being a particular type of multimedia services. Multimedia services are 
classified into categories with similar functional characteristics. The six categories are multimedia conference services, 
multimedia conversational services, multimedia distribution services, multimedia retrieval services, multimedia 
messaging services and multimedia collection services. 

The rest of clause 6 describes the teleservices and options that shall be provided. 

A teleservice can be viewed as set of upper layer capabilities utilising the lower layer capabilities described by the set of 
attributes in clause 5. 

Multimedia teleservices support the transfer (and in some case retrieval, messaging, distribution) of several types of 
information (service components). For this reason, there are service attributes (relating to all the components of a 
teleservice) and service component attributes (relating to only one service component). 



6.3 Support of teleservices 



The realisation of teleservices requires the association of terminal and network capabilities. In the terminals and in the 
network, both upper layer capabilities and lower layer capabilities are necessary. The term upper layer capabilities is 
used because it relates to the OSI upper layers. Decoupling between upper layers and lower layers (transfer) is required. 
Even if this de-coupling may impact radio interface optimisation, it is nevertheless the only way of designing a system 
that is not outdated; 

Each time the information rate associated with an already supported teleservice is decreased by more efficient 
source coding techniques. 

Each time a new service is introduced that requires transfer capabilities not used by currently available 
teleservices. 

Taking the example of two application that exchange information through a teleservice, the upper layer capabilities can 
be located in various places; 
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In the two terminals if the two applications are connected to a PLMN. 

PLMN 



Application 



Application p 



Figure 2; PLIVIN teleservice 



In the terminal of the application connected to a PLMN and in the upper layer interworking unit that is at the border of 
the PLMN and the target network if one application is connected to a PLMN and the other one is connected to another 
type of system. The upper layer interworking unit makes the adaptation between the PLMN and the target network at a 
service level. 



PLMN 



Target network 



Application 



Lower Layer Interconnection 
Unit 

Figure 3; Teleservice with upper layer interworking 



Application 



In the terminal of the application connected to a UMTS network and in the terminal of the application connected to a 
target network if one application is connected to a UMTS network and the other one is connected to another type of 
system, but only lower layer interconnecting unit is used at the border of the two networks. In this case, the 
interconnecting unit makes the adaptation between the UMTS network and the target network at the transmission level. 



UMTS network 



Target network 



Application 



Lower Layer Interconnection 
Unit 

Figure 4; Teleservice with lower layer interworking 



Application 



6.4 Existing Teleservices supported by PLIVIN 

The subset of standardised teleservices shall be supported for interworking with teleservices provided on other 
networks. The means to support the following set of teleservices will be standardised; 

- Speech; 

- Emergency call; 
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Short message service; 
TS 22.003 [3] describes the circuit teleservices. 

6.4.1 Speech 

The speech service as defined in international standards should be supported. The international reference for the speech 
is ITU E.105 recommendation. Networks should contain interworking units which allow calls to be received from or 
destined to users of existing networks like PSTN or ISDN. This will include interworking units for generation of DTMF 
or other tones (the entire DTMF tone set would at minimum be available) and detection of DTMF tones. 

A default speech codec shall be specified to provide speech service. The selected speech codec shall be capable of 
operating with minimum discernible loss of speech on handover between the GSM access network and UTRAN. 

6.4.2 Emergency Call 

This service will use a speech component. There are however compared to telephony reduced authentication 
requirements and a requirement for specific routing. Additionally Emergency Calls may have higher priority than 
normal calls... See TS 22.101[9] for further details. 

6.4.3 Short Message Service - Point to Point (SMS-PP) 

A short message service point to point shall be supported. The short message service shall be provided seamlessly (as 
far as the user or the users terminal equipment is concerned) across the UTRAN and GSM access network. 

6.4.4 Short Message Service - Cell Broadcast (SMS-CB) 

A short message service cell broadcast shall be provided seamlessly (as far as the user or the users terminal equipment 
is concerned) across the UTRAN and GSM network. 

6.5 Internet Access 

3GPP specifications shall provide the means to interwork with external data networks. This interworking shall satisfy, 
within the constraints introduced by the mobile radio environment, the QoS requirements of the interworked-with 
network. The Internet is seen as the most important interworked-with network, therefore the specification of an 
optimised access to Internet will be part of the 3GPP specifications. The most important benefits achieved by the 
definition of Internet Access would be: 

Optimised transmission of IP traffic over the radio interface to minimise the amount of information transmitted. 

Optimised usage of encryption protocols/algorithms over the radio interface. 

Inter-operation of QoS mechanisms. 

For the purposes of optimised access to Internet one or more of the generic bearers will be used. The QoS mechanisms 
defined for packet access mode will be harmonised with those defined for Internet (e.g. Differentiated Services). 



7 Supplementary Services 



Supplementary services are used to complement and personalise the usage of basic telecommunication services (bearer 
services and teleservices). The capabilities standardised shall enable all the supplementary services specified in TS 
22.004 [4] to be provided. 



8 Service Capability features 



Services Capability Features are open, technology independent building blocks accessible via a standardised 
application interface. This interface shall be applicable for a number of different business and applications domains 
(including besides the telecommunication network operators also service provider, third party service providers acting 
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as HE-VASPs, etc.). 

All of these businesses have different requirements, ranging from simple telephony and call routing, virtual private 
networks, fully interactive multimedia to using UE based applications. 

The service capability features shall enable applications to make use of the service capabilities (e.g. CAMEL, MExE, 
etc) of the underlying network in an open and secure way. 

Application/Clients access the service capability features via the standardised application interface. This means that a 
single service capability feature is accessible and visible to application/clients via the method/operation invocations in 
the interface. 

Two different types of service capability features can be distinguished: 

• Framework service capability features: these shall provide commonly used utilities, necessary for the non- 
framework service capability features to be accessible, secure, resilient and manageable. 

• Non-Framework service capability features: these shall enable the applications to make use of the functionality 
of the underlying network capabilities (e.g. User Location service capability features). 

For further information see TS 22.121 [10]. 

8.1 Framework service capability features 

Framework service capability features will be used e.g. for authentication, registration, notification, etc. and provide 
functionality that is independent of any particular type of service. Other commonly used service capability features may 
be added later. 



Examples of Framework Service Capability features are (TS 22.121[10] ): 

• Authentication 

• User-Network Authentication 

• Application-Network Authentication 

• User- Application Authentication 

• Authorisation 

• Application-Network Authorisation 

• User-Application Authorisation 

• Registration 

• Discovery 

• Notification. 

8.2 Non-Framework service capability features 

The Non-Framework service capability features represent the total collection of service capability features that are not 
included in the Framework. These non-framework service capability features enable the application to make use of the 
functionality provided by the network and service capabilities. 

Service capability features shall be defined as much as possible in a generic way to hide the network specific 
implementation. To achieve this, it is necessary to identify the functionality that is provided by more than one service 
capabilities. For example. User Location can be produced in several underlying ways. This functionality can be 
captured once when defined the service capability features in a generic way. It is important that the generic part 
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becomes as large as possible. 

When applications use the generic service capability features, these applications become independent of (portable over) 
underlying service capabilities. Applications shall however still be able to request service capability features specific to 
a service capability (e.g. Call Setup from CAMEL). This will increase dependency of the used service capability. 



Examples of Non-Framework service capability features are (TS 22.121 [10]): 

• Session Control 
Security/Privacy 

• Address Translation 

• Location 



• 



The precision of the location shall be network design dependent, i.e. an operator choice. This precision may vary 
from one part of a network to another. It may be chosen to be as low as hundreds of meters in some place and as 
accurate as 5 meters in other place. It is required that a minimum precision of around 50 meters can be achieved 
in all types of terrestrial radio environment. Technical issues may constrain the precision to be mobile state 
dependent as well (mobile idle / mobile in communication). Several design optional features (e.g. size of the cell, 
adaptive antenna technique, path loss estimation technique...) shall allow the network operator to reach cost 
effectively the target precision. 

Because there may be very different uses of the location information; 

It shall be possible to make the information available to the user, HE/SN and value added service providers. 
The user shall be able to restrict access to the location information (permanently or on a per call basis). The 
restriction can be overridden by the network operator when appropriate (e.g. emergency calls). 



It shall be possible to set the delay to get the location information (the situation is quite different whether the 
information is needed for call routing or if it is needed by a user application). 

It shall be possible to select the frequency of the location information update. 

to identify and report when the user's terminal enters or leaves a specified geographic area. 

It shall be possible to specify the area as a circular zone (centre and radius) to a resolution that will be limited by 
the accuracy capability of the part of the serving network where the user is registered. 

User Status 

Terminal Capabihties 

Messaging 

Data Download 

User Profile Management 

Charging 

9 Standardised Protocols and Capabilities 

This clause introduces a list of standardised protocols and capabilities that shall be supported for the control and 
creation of services. The access protocols and the execution environment described below are essential. 



9.1 Access protocols 



The access protocols shall allow the support of multimedia services. These services are characterised by the ability to 
dynamically change the number of participants and the number of connections during a call. The characteristics of the 
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connections (confer the list of attributes used to describe a connection) may differ from one connection to another. They 
are negotiated during call set-up. They may be independently and dynamically re-negotiated on application (the 
telecommunication requirements of the application changes) or network initiative (change of network load conditions, 
during a handover procedure) during the call. 

The application may require synchronisation between some of the connections. Later, this synchronisation shall not be 
lost during handover procedures. 

Whenever a call is terminated in other types of networks, the negotiation shall take into account the limitations of these 
networks. Interworking shall be possible with PLMN, PSTN, ISDN and Internet networks. The access protocols shall 
allow a user equipment to have several calls active simultaneously. 



9.2 



Execution Environment 



The execution environment is a set of standardised capabilities that shall allow the support of HE/SN specific services 
(i.e. both applications, teleservices and supplementary services). The execution environment shall be distributed 
between the IC card, terminal and network nodes. The terminal and the serving network capabilities shall be the only 
limiting factor for the support of the services designed to run on the execution environment. The execution environment 
is composed of the following building blocks; 

A standardised content description language for support of HE/SN specific user interfaces (both for information 
output and user input). This is intended only for platforms which are terminals. 

A standardised procedural language for support of HE/SN specific scripts. This language shall be common to all 
types of platforms. The scripts could be used for e.g. improving the user interface, adding new features to the 
terminal like the latest version of a codec, controlling the execution of a service. 

Standardised application programming interfaces for opening platform resources and capabilities to the scripts 
written with the standardised procedural language. These interfaces would be platform type dependent. The 
interfaces shall include primitives for accessing to the basic control functions, as illustrated on the figures 5 and 
6 below. 



Execution Environment 



Service 
Logic 1 



Service 
Logic 2 



Service 
Logic N 




Mobility 
Man. 



Call/Session 
Control 



Bearer 
Control 



Terminal/IC card 



Figure 5: Execution Environment in the User Equipment 
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Execution Environment 



Service 
Logic 1 



Service 
Logic 2 



Service 
Logic N 




Mobility 
Man. 



Call/Session 
Control 



Bearer 
Control 



Network 



Figure 6: Execution Environment in the Network 

Call states, messages, information elements, values of information elements shall serve as triggers for subsequent 
interaction with service logic. The list of triggers shall incorporate those provided by CAMEL, SIM Toolkit, 
MExE. 

Means to turn triggers on and off, and associate them with service logic will be standardised. 

A standardised certification scheme and security model with several levels of trusts in order to control the scripts 
access rights to the platform resources and capabilities. This would be used to allow e.g. the SP and the HE only 
to access to SIM/USIM data. 

Standardised protocols for allowing the download of content description pages and scripts in the platform. 



1 Access dependent services and features 

This section describes the features that will be dependent on the mode of radio access. 
In general different access networks provide different capabilities with different QoS. 

Multicall, as specified in TS 22.135 [11], is supported only via UTRAN. 

Packet switched traffic using GPRS over GERAN will have a maximum rate in the order of 384kb/sec. 

Packet switched traffic using UTRAN will have a maximum rate in the order of 2Mb/sec. 
- ASCI teleservices, TS 22.003 [3] are only available in GERAN. 

The accuracy of the determination of location may differ between the various access technologies. 

At GERAN reception of CBS messages for a UE is not supported if it is connected in the CS domain or in the 
PS domain when data is currently transmitted. 

Transparent (T) fax as specified in TS 22.003 [3] is only supported by UTRAN. 

Non-transparent fax (NT) as specified in TS 22.003 [3] is only supported by GERAN. 

Note: Differences of SoLSA features between GERAN and UTRAN is FES. 
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Annex A (informative): 

Examples of services built from service capabilities features 

Call Barring 

In standard GSM, the Call Barring services allow to prevent outgoing calls to certain sets of destinations, based on the 
number dialled and whether the user is roaming. It is proposed that this service allows to block outgoing calls based on 
a wider range of parameters which could include factors such as the time of day, day of week, location, type of call 
requested, cost of the service and/or destination. This would allow to develop Call Barring services tailored to business 
and personal markets to avoid abuse. 

This service is invoked during the initial outgoing call set-up procedure and allow the call to be blocked prior to 
incurring any charges. This Service can be applied to any teleservice for both connection-oriented and connectionless- 
oriented services. 

Call Filtering/Forwarding 

In standard GSM, there is no call filtering service. All calls are presented to the user unless a call forwarding service is 
used to re-direct calls; there is no different call handling depending on the incoming call parameters (although 
differentiation on call type (voice/data) is possible). 

The call filtering service allows the control of whether incoming calls are accepted, forwarded or terminated. The 
parameters which can be used to determine the final destination of a call may include the caller ID (CLI), original 
number dialled, time of day, current user location/network, user profile settings and current state of the terminal. 

This service shall be two-stage; immediate call filtering (handled regardless of whether the terminal is online or not) 
and late call filtering (handled only if the terminal is online). It shall be possible to create and operate new call filtering 
services which can access any of the key parameters to handle calls in this way. 

Hold 

This service allows an established call to be maintained, whilst suspending use of the bearer from the incoming access 
point of the network. This saves on both air interface and network traffic resources when a call is temporarily 
suspended. The incoming access point in the network means either the originating terminal, or interworking point with 
another network. 

Transfer 

This service allows either an established or held call to be redirected to another destination. This may either be used by 
setting up a new call to the destination first, or simply redirecting the existing call to the new destination. It shall be 
possible to revert such a call back to the diverting terminal at any time before it is accepted (answered) by the new 
destination. The system shall ensure that an optimal traffic route is used after the call has been answered by its new 
(final) destination. 

Call-back When Free 

This service can be invoked where a call (or a connectionless message) cannot be delivered to its destination because it 
is in use. The system shall inform the requesting entity when the destination is next able to accept the call, allowing a 
new call to be originated. This allows existing GSM services, such as Call-back When Free to be implemented. Where 
multiple requests are outstanding for a terminal which becomes available, the system shall determine in which order the 
requests are handled, probably in a serial manner. Ideally, it shall be possible to create the service logic which 
determines the order used from a range of accessible parameters. 
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Annex B (informative) : 

Description and analysis of communication schemes 

This annex gives a high level classification and description of communications requirements from end users 
and applications. 

B.1 Communication schemes 

The requirements on bearer services are based on an analysis of user and application needs. Four end-user 
groups are identified according to four distinctly different communication schemes; Conversational - real 
time, Interactive services, Streaming services and Background services. 

B.2 QoS related performance requirements for example 
end user applications 

A typical user is not concerned with how a particular service is provided. However, the user is interested in 
comparing one service with another in terms of universal, user-oriented performance parameters which apply 
to any end-to-end service. From a user's perspective, performance should be expressed by parameters which: 

• Focus on user-perceivable effects, rather than their causes within the network 

• Are independent of the networks internal design 

• Take into account all aspects of the service from the user's point of view which can be objectively 
measured at the service access point 

• Can be assured to a user by the service providers(s) 

With these considerations in mind, this section examines the requirements of typical end user applications 
that can be expected. 

B.2.1 Performance requirements for conversational real-time 

The most well known use of this scheme is telephony speech (e.g. GSM), but with Internet and multimedia a 
number of new applications will require this scheme, for example voice over IP and video conferencing 
tools. Real time conversation is always performed between peers (or groups) of live (human) end-users. This 
is the only scheme where the required characteristics are strictly given by human perception (the senses). 
Therefore this scheme raises the strongest and most stringent QoS requirements. 

The real time conversation scheme is characterised by that the transfer time shall be low because of the 
conversational nature of the scheme and at the same time that the time relation (variation) between 
information entities of the stream shall be preserved in the same way as for real time streams. The maximum 
transfer delay is given by the human perception of video and audio conversation. Therefore the limit for 
acceptable transfer delay is very strict, as failure to provide low enough transfer delay will result in 
unacceptable lack of quality. The transfer delay requirement is therefore both significantly lower and more 
stringent than the round trip delay of the interactive traffic case. 

Real time conversation - fundamental characteristics for QoS: 

• preserve time relation (variation) between information entities of the stream 

• conversational pattern (stringent and low delay) 



£75/ 



(3G TS 22.1 05 version 3.7.0 Release 1 999) 28 ETSI TS 1 22 1 05 V3.7.0 (2000-01 ) 



The resulting overall requirement for this communication scheme is to support conversational real time 
services with low transfer delay as given by the human perception. (There are less hard requirements on 
packet loss ratio.) 

A real-time streaming application is one that delivers time -based information in real-time, where time-based 
information is user data that has an intrinsic time component. Video, audio and animation are examples of 
time -based information, in that they consist of a continuous sequence of data blocks that shall be presented to 
the user in the right sequence at pre -determined instants. 

Conversational voice 

Audio transfer delay requirements depends on the level of interactivity of the end users. To preclude 
difficulties related to the dynamics of voice communications, ITU-T Recommendation G.114 recommends 
the following general limits for one-way transmission time (assuming echo control already taken care of): 

to 150 ms preferred range [<30ms, user does not notice any delay at all, <100ms, user does not 

notice delay if echo cancellation is provided and there are no distortions on the link] 

150 to 400 ms acceptable range (but with increasing degradation) 

above 400 ms unacceptable range 

The human ear is highly intolerant of short-term delay variation (jitter) it is therefore paramount that this is 
reduced as lower level as is practical. A limit as low as 1 msec is suggested as a target. 

Requirements for information loss are influenced by the fact that the human ear is tolerant to a certain 
amount of distortion of a speech signal. It is has been suggested in studies that acceptable performance is 
typically obtained with frame erasure rates (FER) up to 3 %. 

A connection for a conversation normally requires the allocation of symmetrical communication resources, 
with the average hold time of a call being in the region of 2 minutes. 

Videophone 

Videophone implies a full-duplex system, carrying both video and audio and intended for use in a 
conversational environment. As such, in principle the same delay requirements as for conversational 
voice will apply, i.e. no echo and minimal effect on conversational dynamics, with the added 
requirement that the audio and video must be synchronised within certain limits to provide "lip- 
synch" (i.e. synchronisation of the speaker's lips with the words being heard by the end user). In 
fact, due to the long delays incurred in even the latest video codecs, it will be difficult to meet these 
requirements. 

Once again, the human eye is tolerant to some loss of information, so that some degree of packet 
loss is acceptable depending on the specific video coder and amount of error protection used. It is 
expected that the latest video codecs will provide acceptable video quality with frame erasure rates 
up to about 1%. 

Interactive games 

Requirements for interactive games are obviously very dependent on the specific game, but it is clear that 
demanding applications will require very short delays, and a value of 250 msecs is proposed, consistent with 
demanding interactive applications. 

Two-way control telemetry 

Two-way control telemetry is included here as an example of a data service which does require a real-time 
streaming performance. Clearly, two-way control implies very tight limits on allowable delay and a value of 
250 msec is proposed, but a key differentiator from the voice and video services in this category is the zero 
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tolerance for information loss (obvious if you are controlling an important industrial process, for example). 

Telnet 

Telnet is included here with a requirement for a short delay in order to provide essentially instantaneous 
character echo-back. 

B.2.2 Performance requirements for Interactive Services 

When the end-user, that is either a machine or a human, is on line requesting data from remote equipment 
(e.g. a server), this scheme applies. Examples of human interaction with the remote equipment are: web 
browsing, data base retrieval, server access. Examples of machines interaction with remote equipment are: 
polling for measurement records and automatic data base enquiries (tele-machines). 

Interactive traffic is the other classical data communication scheme that on an overall level is characterised 
by the request response pattern of the end-user. At the message destination there is an entity expecting the 
message (response) within a certain time. Round trip delay time is therefore one of the key attributes. 
Another characteristic is that the content of the packets must be transparently transferred (with low bit error 
rate). 

Interactive traffic - fundamental characteristics for QoS: 

- request response pattern 

- preserve payload content 

The resulting overall requirement for this communication scheme is to support interactive non-real time 
services with low round-trip delay. 

Voice messaging and dictation 

Requirements for information loss are essentially the same as for conversational voice, but a key difference 
here is that there is more tolerance for delay since there is no direct conversation involved. The main issue, 
therefore becomes one of how much delay can be tolerated between the user issuing a command to replay a 
voice message and the actual start of the audio. There is no precise data on this, but a delay of the order of a 
few seconds appears reasonable for this application. 

Data 

Although there may be some exceptions, as a general rule it is assumed that from a user point of view, a 
prime requirement for any data transfer application is to guarantee essentially zero loss of information. At the 
same time, delay variation is not applicable. The different applications therefore tend to distinguish 
themselves on the basis of the delay which can be tolerated by the end-user from the time the source content 
is requested until it is presented to the user. 

Web-browsing 

In this category we will refer to retrieving and viewing the HTML component of a Web page, other 
components eg images, audio/video clips are dealt with under their separate categories. From the user point 
of view, the main performance factor is how fast a page appears after it has been requested. A value of 2-4 
seconds per page is proposed, however improvement on these figures to a target figure of 0.5 seconds wound 
be desirable. 

High-priority transaction services (E-commerce) 

The main performance requirement here is to provide a sense of immediacy to the user that the transaction is 
proceeding smoothly. A value of 2-4 seconds is suggested to be acceptable to most users. 
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E-mail (server access) 

E-mail is generally thought to be a store and forward service which in principle can tolerate delays of several 
minutes or even hours. However, it is important to differentiate between communications between the user 
and the local email server and server to server transfer. When the user communicates with the local mail 
server, there is an expectation that the mail will be transferred quite rapidly, although not necessarily 
instantaneously. Consistent with the research findings on delay tolerance for Web-browsing, a requirement 
of 2-4 seconds is proposed. 

B.2.3 Performance requirements for streaming services 

When the user is looking at (listening to) video (audio) the scheme streams applies. The real time data flow 
is always aiming at a live (human) destination. It is a one way transport. 

This scheme is one of the newcomers in data communication, raising a number of new requirements in both 
telecommunication and data communication systems. First of all it is a mainly unidirectional stream with 
high continuous utilisation (i.e. having few idle/silent periods.) It is also characterised by that the time 
relations (variation) between information entities (i.e. samples, packets) within a flow must be preserved, 
although it does not have any requirements on low transfer delay. 

The delay variation of the end-to-end flow must be limited, to preserve the time relation (variation) between 
information entities of the stream. But as the stream normally is time aligned at the receiving end (in the user 
equipment), the highest acceptable delay variation over the transmission media is given by the capability of 
the time alignment function of the application. Acceptable delay variation is thus much greater than the delay 
variation given by the limits of human perception. 

Real time streams - fundamental characteristics for QoS: 

• unidirectional continuous stream 

• preserve time relation (variation) between information entities of the stream 

The resulting overall requirement for this communication scheme is to support streaming real time services 
having unidirectional data flows with continuous utilisation. (There are less stringent requirements on delay 
and packet loss ratio, i.e. the ratio of lost or corrupted packets out of all packets sent.) 

Audio streaming 

Audio streaming is expected to provide better quality than conventional telephony, and requirements for 
information loss in terms of packet loss will be correspondingly tighter. However, as with voice messaging, 
there is no conversational element involved and delay requirements can be relaxed, even more so than for 
voice-messaging. 

One-way video 

The main distinguishing feature of one-way video is that there is no conversational element involved, 
meaning that the delay requirement will not be so stringent, and can follow that of streaming audio. 

Bulk data 

This category includes file transfers, and is clearly influenced by the size of the file. As long as there is an 
indication that the file transfer is proceeding, it is reasonable to assume some what longer tolerance to delay 
than for a single Web-page. 

Still image 

This category includes a variety of encoding formats, some of which may be tolerant to information loss 
since they will be viewed by a human eye. However, given that even single bit errors can cause large 
disturbances in other still image formats, it is argued that this category should in general have zero 
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information loss. However, delay requirements for still image transfer are not stringent, given that the image 
tends to be built up as it is being received, which provides an indication that data transfer is proceeding. 

Telemetry (monitoring) 

Monitoring covers a wide range of applications, but in this category it is taken to apply to relatively low 
priority activities, e.g. status updating, rather than control. 

B.2.4 Performance requirements for Background applications 

When the end-user, that typically is a computer, sends and receives data-files in the background, this scheme 
applies. Examples are background delivery of E-mails, SMS, download of databases and reception of 
measurement records. 

Background traffic is one of the classical data communication schemes that on an overall level is 
characterised by that the destination is not expecting the data within a certain time. The scheme is thus more 
or less delivery time insensitive. Another characteristic is that the content of the packets must be 
transparently transferred (with low bit error rate). 

Background traffic - fundamental characteristics for QoS: 

• the destination is not expecting the data within a certain time 

• preserve payload content 

The resulting overall requirement for this communication scheme is to support non-real time services 
without any special requirement on delay. 

A background application is one that does not carry delay information. In principle, the only requirement for 
applications in this category is that information should be delivered to the user essentially error free. 
However, there is still a delay constraint, since data is effectively useless if it is received too late for any 
practical purpose. 

Fax 

Fax is included in this category since it is not normally intended to be an accompaniment to real-time 
communication. Nevertheless, there is an expectation in most business scenarios that a fax will be received 
within about 30 seconds. The information loss requirement is based on established wireline requirements for 
a Group 3 fax. As for the symmetry this should provide the required through put in the sending direction and 
the control signalling in backwards direction, hence an asymmetric connection is required. 

Low priority transaction services 

An example in this category is Short Message Service (SMS). 30 seconds is proposed as an acceptable 
delivery delay value. 

Email (server to server) 

This category is included for completeness, since as mentioned earlier, the prime interest in email is in the 
access time. There is a wide spread in user expectation, with a median value of several hours. 



B.3 Adaptability and bearer service negotiation 

Applications using the interactive or real time conversational communication schemes can also be described 
according to their possibilities for adapting to different environmental conditions as follows: 

• Rigid applications; these applications can not adapt at all (e.g. GSM full rate speech.) 
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• Adaptive applications; these applications can adapt to the environment; they therefore require the 
network to support service negotiation, (e.g. multi-rate speech codecs) 

• Elastic applications; these applications adapt totally to the environment and do therefore not require 
service negotiation (e.g. web browsing.) 

The resulting overall requirement is to support service negotiation. 
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